Harden PyPI install verification against stale cache - #102

What changed

• force every post-publish install attempt to bypass pip's HTTP cache
• explicitly verify against the canonical https://pypi.org/simple/ index
• use python -m pip consistently for install/uninstall
• extend verification from 10 minutes (30 × 20s) to 30 minutes (60 × 30s) and avoid sleeping after the final failure
• on failed attempts, log when the release already exists on the JSON API — making "index propagation delay" distinguishable from "publish actually failed" in the logs
• quote workflow output files and the version-check URL so the workflow passes actionlint

The verify step is now line-for-line consistent with the same hardening in SocketDev/socket-python-cli#290.

Why

The 3.4.2 release uploaded both distributions successfully, and PyPI's JSON API/project page showed the release, but the post-publish pip install socketdev==3.4.2 loop repeatedly saw a stale Simple-index response whose version list ended at 3.3.0. It ultimately exhausted all 30 attempts and failed after 10m52s.

pip caches HTTP responses by default. If the first install attempt races PyPI index propagation, the existing loop can reuse that initial stale response on every retry. It also performs its 30 checks at roughly 0–580 seconds and then sleeps once more before failing, so it never makes a post-expiry check beyond the Simple index's observed 10-minute cache lifetime.

Root cause findings (cross-repo)

This was not specific to this repo or release. socket-python-cli hit the identical failure the same day: socketsecurity v2.5.9 (uploaded 16:40 UTC) failed its release verify loop with the Simple index stuck at 2.5.8 for the full 10-minute budget, which also skipped its Docker publish. Two independent packages, seven hours apart, same signature: JSON API fresh immediately, CDN-cached Simple index stale for 10+ minutes.

Notably, while this repo's verify loop was failing (23:30–23:39 UTC), other CI runners were successfully installing socketdev==3.4.2 from PyPI — the staleness was specific to individual CDN cache nodes, i.e. a delayed/partial purge propagation on PyPI's side. PyPI's status page reported no incident, and pip was ruled out as a cause (the previous day's successful releases used the same pip 26.2.1). Both indexes recovered on their own.

This is a latent race rather than a package compatibility failure. The same verification loop was present in the successful 3.3.0 release, where attempt 1 missed the new version and attempt 2 happened to find it 20 seconds later — the propagation lag has always existed; on 2026-08-05 it grew past the loop's budget.

With this change, every retry performs a fresh lookup and the retry budget extends well beyond the observed staleness window.

Validation

• actionlint .github/workflows/release.yml
• parsed .github/workflows/release.yml with Ruby's YAML parser
• git diff --check

References

Prior reports of the same PyPI Simple-index staleness class:

• PyPI caching packages too long (updated release still not showing up after 12 hours after upload) pypi/warehouse#17179 — PyPI caching packages too long (release not in index hours after upload)
• New packages not appearing in pypi.org/simple index pypi/warehouse#8416 — New packages not appearing in pypi.org/simple index
• New packages not appearing in pypi.org/simple index pypi/warehouse#5017 — New packages not appearing in pypi.org/simple index